The present disclosure relates to aspects of electronic directories, and relates in particular to improvements to the use of automatically-generated user identifiers within electronic directories.
Electronic data stores and computerized directories have begun to utilize distributed aspects, where directory functionality and data itself is spread over multiple servers, networks, etc. Distributed directories may benefit from increased high-volume and globalized capability, and may dynamically replicate entries as needed. Some temporary inconsistencies may exist between machines in distributed models for a short amount of time, but any inconsistencies are typically addressed quickly. However, as electronic directories proliferate, a relative disorder of platform or company-specific versions led to an eventual need for a platform-independent, standardized, and Internet-connected model. The X.500 directory standard, which runs on Open Systems Interconnection (OSI), accomplishes some of the goals, but has known drawbacks. For one, X.500 runs on the OSI protocol stack (as opposed to the widely-used transmission control protocol and Internet protocol suite (TCP/IP) or other connection-oriented transfer service), and had robust, or “heavyweight,” features and capacities that were often neither needed nor used.
Lightweight directory access protocol (LDAP) was developed to be an application and distributed directory access protocol that could be used across platforms and/or organizations, among other flexibilities. Generally speaking, the formulation of LDAP eschews various components and functionalities of the broader-scope X.500, while streamlining others (e.g., the shift from OSI to TCP/IP), leading to an efficient, and widely-disseminated protocol for distributed or large-scale directory management. LDAP utilizes a client-server model, whereby a user (or a device) can connect to any of several servers and still access the same entry, in the form of a global directory service. In order to keep entries organized and logically laid out, LDAP entries are generally arranged in a hierarchical tree-like structure, and ordering of entries is not typically required.
A general purpose and goal of LDAP, unlike some other database-type formats, relates to streamlining and improving usefulness and efficiency in directories, generally including information relating to individuals, stored in the form of entries. The various entries (which may represent, for example, individuals) are assigned a unique identifying name (called a distinguished name (DN)), details and characteristics, such as a first and/or last name, user role, phone number, email address, employee number, office location, common name, home directory, password, etc.
In order to run large-scale, global, or distributed databases or data systems, various computer systems, including high-performance computing (HPC) implementations, have become increasingly integrated. The implementation of HPCs, among others, has led to an increase in various administrative and management demands related to database and directory models. Due to issues with permissions of administrator accounts, security-related aspects often have inherent vulnerabilities. To improve security, in particular, LDAP may be employed as a back-end to store and authenticate the multiple created administrative accounts.
LDAP often utilizes one or more so-called “schemas” related to various tasks or directory functions, LDAP also employs entries, which may be prescribed and governed by a schema. A schema is often a grouping of fundamental information categories known as entries. Each schema is composed of mandatory and/or optional entry information categories and which may serve as frameworks or templates for various directory-related database organizations. An entry, for the purposes of the LDAP framework, include attributes which may have a name and one or more values related to an object (e.g., an employee, administrator, system, etc.). The attributes may include qualities or names related to the object in question, such as a unique, user identifier (UID) for a particular user's account, among many other attributes. A UID, as the name implies, is typically an identifier or serial number that identifies a user entry (e.g., a human user or device), and a UM may be referred to as a distinguished name (DN) (including a full filesystem file path), or a relative distinguished name (RDN) (the relevant filesystem file name in its relevant parent folder). A DN may change over time, as needed, for example if an entry is moved from one location to another.
At present, administrator(s) typically must provide, assign, and/or create UIDs manually, a process that is prone to errors among other problems. As such, it has become increasingly important to devise a method for generating (e.g., in conjunction with the LDAP ADD operation) UIDs and adding associated entries without problematic overwrites, collisions, security concerns or other problems. Generally, the ADD operation involves the insertion a new entry (e.g., a UID) into a directory or server database. If the UID in the add request already exists in the directory, then the server will not or cannot add a duplicate entry, but may give an error or result code of “entry already exists.” Typically, in order to add a new entry in an LDAP environment, the new entry to be added must not already exist, and the new entry's immediate superior in the hierarchy or directory must exist.
Various problems exist with respect to the capabilities and functionality of the existing state of the named account feature. Typically, there has been no enforcement of password expiration policy for a default administrator “admin” account. Additionally, there has typically been no enforcement to check the strength of the password. With regard to an audit of the administrator account, there typically has been no separate audit, with the possible exception of the unreliable bash history. Furthermore, typically there has been no separate account for other management-related access (e.g., with respect to reliability, availability, and/or service).